Agent interworking protocol and call processing architecture for a communications system

ABSTRACT

A call processing architecture treats a call connection as having two halves an originating half and a terminating half. An agent is associated with each call half, the originating agent being assigned by a switching center of a telecommunications system to establish the originating half of a call. The originating agent interacts with a translator and router to process the dated digits for a call to route the call to a terminating agent, the terminating agent establishing the terminating half of the call to complete the call connection. An agent interworking protocol (AIP) provides a generic superset protocol containing the common elements and unique elements for all call types so that an originating agent converts its call messages to the AIP and is connected to a terminating agent via an AIP connector, the terminating agent converting the AIP formatted call messages to the native protocol of the terminating agent. Agents for different call types are each able to convert call messages to or translate call messages from the agents&#39;s unique protocol to the AIP format and each type of agent does not need to know the type of agent being connected to as communication with other agents is via the AIP.

CLAIM OF PRIORITY

The instant patent application claims priority from the United Statesprovisional patent application designated with Ser. No. 60/060,107,entitled Cellular Communication System, filed on Sep. 26, 1997.

FIELD OF THE INVENTION

The present invention relates to call processing in a communicationssystem. More particularly, the present invention relates to a callprocessing architecture and a generic call message protocol forprocessing multiple types of calls.

BACKGROUND INFORMATION

In wireless communications systems, such as an Analog Mobile PhoneSystem (AMPS) or a Global Standard for Mobile Communications (GSM)system, call processing includes call origination and termination. Forexample, a call originated by a wireless calling party to a wirelinecalled party must be connected through a mobile communications network,such as a Public Land Mobile Network (PLMN), to a land-basedcommunications network, such as a Public Switched Telephone Network(PSTN). The setup of the call, however, often involves different typesof calls (e.g., different trunking protocols such as GSM, ISUP, TIJP andR2) required to establish a call connection, each trunking protocolrequiring a call state machine capable of originating and terminatingcalls for the particular call types. Each call state machine cangenerate and communicate its own types of messages (e.g., call setupsignaling) but the call setup messages for different call types areincompatible with the call setup messages of other call types. Callsetup messages include information such as calling party number, calledparty number, call type (e.g., data or voice) and other informationneeded by the particular call type.

In conventional communication systems, there may be a single agent, forexample a software entity, capable of handling the call messaging forall call types or an agent for each call type involved in establishing acall connection. A problem arises, however, in the interworking of thedifferent external interfaces for different call types as the callsignaling for each call type involved in establishing a single callconnection may be unique and incompatible with other call typesignaling. Thus, in conventional communication systems, each agent(whether a single agent for all call types or a separate agent for eachcall type) requires knowledge of each call type handled by thecommunications system, thereby adding complexity to each agent as wellas presenting integration and maintainability problems as more calltypes are added to the communications system.

SUMMARY OF THE INVENTION

According to an exemplary embodiment of the present invention, a callprocessing architecture processes each call as having an originatinghalf and a terminating half and an agent is assigned to setup, processand terminate each call half. An originating agent is assigned by, forexample, a switching center of a telecommunications system. Theoriginating agent establishes an originating half of a call andinteracts with a translator and router to process the dialed digits androute the call to a terminating agent, the terminating agentestablishing the terminating half of the call and thereby completing thecall connection. If the terminating agent cannot complete the call orneeds to redirect the call for any reason, additional agents can beconnected to the terminating agent as necessary to complete the call, aterminating agent also being capable of operating as an originatingagent.

For example, if a call originates on a mobile network, such as a GSMsystem, then a mobile agent would control the call setup on the mobilenetwork, e.g., control the connection of the mobile station to the basestation controller (BSC) and mobile switching center (MSC) of the mobilenetwork. The mobile agent could reside, for example, in the callprocessor portion of the MSC which in turn controls a resource shelfcontaining the line cards which physically perform the setup of thecall. Thus, the mobile agent establishes the originating half of thecall. The mobile agent would interact with a translator and router todetermine thc terminating agent and facilitate connection of theoriginating and terminating agents. Assuming, for example, that the callis to be routed to a PSTN of the called party, it is likely thatSignaling System 7 (SS7) is used for signaling on the PSTN. As part ofSS7, Integrated Services Digital Network User Part (ISUP) provides fortransfer of call setup signaling information between signaling points.Thus, to complete the call, an ISUP agent, for example also residing inthe MSC, would be allocated as the terminating agent to control thesetup of the call to the PSTN via the ISUP protocol, thus establishingthe terminating half of the call. Similarly, if the destination networkof the terminating half of the call required the TUP protocol (e.g.,Telephone User Part, the predecessor to ISUP) or the R2 protocol (e.g.the European analog and digital inband trunk signaling protocol) or anyother protocol, an agent for each protocol would be available so thateach call type could be processed by the mobile network to establish thecomplete connection for the call.

According to another exemplary embodiment of the present invention, anagent interworking protocol (AIP) provides a generic call setupprotocol. The AIP according to the present invention provides a supersetprotocol containing the common elements and unique elements for all calltypes. Thus, according to an embodiment of the present invention, anoriginating agent converts its call setup message to the AIP and isconnected to a terminating agent via an AIP connector, the terminatingagent converting the AIP formatted call setup message to the protocol ofthe terminating agent. Thus, according to an embodiment of the presentinvention, agents for different call types are each able to convert callsetup messages to or translate call setup messages from the agents'sunique protocol to the AIP format. As a result, each type of agent doesnot need to know the type of agent being connected to and only needs tocommunicate with other agents via the AlP according to the presentinvention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an exemplary wireless communication system accordingto an embodiment of the present invention

FIG. 2 illustrates agents connected to a translator and router accordingto an exemplary embodiment of the present invention.

FIG. 3 illustrates an exemplary agent interworking protocol flowaccording to an embodiment of the present invention.

FIG. 4 illustrates exemplary agent connections using an agentinterworking protocol according to an embodiment of the presentinvention.

FIG. 5 illustrates exemplary agent connections using an agentinterworking protocol according to an embodiment of the presentinvention.

FIG. 6 illustrates an exemplary flow chart of call processing accordingto an embodiment of the present invention.

DETAILED DESCRIPTION OF TIME INVENTION

FIG. 1 illustrates an integrated, wireless telecommunications system 100and certain connections associated with that telecommunications system100, in accordance with one embodiment of the present invention. Thetelecommunications system 100 is operable to provide speech and dataservices to multiple subscriber units 110. Each subscriber unit 110provides an interface to a human user, such as through use of amicrophone, loudspeaker, display or keyboard of a subscriber unit, orprovides an interface to terminal equipment, such as an interfacetowards a personal computer or facsimile machine, or both. While thesubscriber units 110 are illustrated in FIG. 1 as hand held mobileunits, it should be appreciated that the subscriber units are not solimited. For example, the subscriber units 110 may comprise a fixedantenna assembly connected to a telephone or other interface device. Asmart card (not illustrated) may be embodied within a subscriber unit110 to provide such subscriber unit with subscriber related informationand encryption keys.

Communications to and from the subscriber units 110 are established overa radio interface 112 by one or more base stations 102. The basestation(s) 102 directly communicate with the subscriber units 110 overradio frequency signals transmitted from, and received by, the basestations over the radio interface 112. The base station(s) 102 may, forexample, include radio transmission and reception devices, antennaassemblies and signaling processing logic specific to the radiointerface 112 between the base station(s) and the subscriber unit(s)110.

A base station 102 is preferably responsible for providingcommunications to subscriber units 110 located within a particularregion, commonly referred to as a service area or cell. One or more basestations 102, typically in a common area, may be logically grouped intowhat is commonly referred to as a site. Further, it should beappreciated that the base station(s) 102 may be interconnected invarious ways. For example, base stations 102 may be interconnected in astar configuration or in series with respect to one another. Thetelecommunications system 100 is connected to the base stations 102 by alink 120, such as an E1 or T1 telecommunications line, that provides oneor more suitable transmission channels. Digital representations ofspeech or data information are transmitted over the link 120 between thetelecommunications system 100 and the base station(s) 102, at apredetermined transmission rate.

The telecommunications system 100 is further connected to a mobilenetwork 104 over a link 114 and a switched network 106 over another link116. The switched network 106, for example, the Public SwitchedTelephone Network or PSTN, typically carries voice and data services tofixed locations. Signals transmitted over the switched network link 116may therefore include ISUP and R2 type signals. Similarly, the mobilenetwork 104, for example, the Public Land Mobile Network or PLMN,typically carries voice and data services to mobile units. Signalstransmitted over the mobile network link 114 may therefore include SS7and MAP type signals in addition to IStJP and R2 type signals.Configuration of the telecommunications system 100 is preferablyaccomplished by a graphical user interface associated with a localterminal 108 over a wireline connection 118 or by a remote terminal 108a over a modem link 118 a.

A resource assembly is preferably included within the telecommunicationssystem 100. That resource assembly 202 is preferably connected, eitherdirectly or indirectly, to the base station(s) 102 over one link 120,the switched network 106 over another link 116, and the mobile network104 over yet another link 114. Within the telecommunications system 100,the resource assembly 202 is preferably connected to a call processorassembly 200 as well as a network management system 204. The resourceassembly 202, in addition to providing an interface to the basestation(s) 102, the switched network 106 and the mobile network 104,includes resources that are available to be used by the call processorassembly 200.

The call processor assembly 200 includes elements that are operable toprocess calls directed to, or received from, the subscriber units 110.The call processor assembly 200 is operable to handle call processingfunctions needed by the telecommunications system 100, including callorig(ination, location updating, handovers between cells, trunking andcall termination. The call processor assembly 200 is a general purposecomputing platform, such as an Intel Pentium II based computingplatform, that comprises suitable hardware and/or software systems tosupport telecommunications processing. The call processor assembly 200may use a real-time operating system such as a QNX operating system tosupport the real-time call processing requirements of telecommunicationssystem 100.

As illustrated, a network management system 204 may be embodied withinthe telecommunications system 100 or external to the telecommunicationssystem 100. Certain elements of the network management system 204 arepreferably provided within the telecommunications system 100 whileothers are provided externally. However, the present invention may bepracticed regardless of how the network management system 204 isimplemented. The network management system 204 is responsible foroperation, administration and maintenance functions for thetelecommunications system 100 and includes, for example, configurationmanagement, performance management, accounting manag ement, faultmanagement, system test and startup and recovery. It should also beappreciated that while the call processor assembly 200, resourceassembly 202 and network management system 204 are illustrated asdistinct entities, some or all of the functionality of those entitiesnevertheless may be integrated into a single entity consistent with thespirit and scope of the present invention.

The call processor assembly 200 of the telecommunications system 100preferably includes two elements, namely, a radio controller 302together with a switching center 304. The radio controller 302, whichmay also be located separate from the call processor assembly 200, isresponsible for management of the base station(s) 102 and their radiointerfaces 112, including the allocation and release of radio channelsassociated with a given radio interface 112 and management of handoversfrom one base station 102 to another base station 102. The radiocontroller 302 manages radio transmission equipment associated with thebase station(s) 102 and may be responsible for management of the radiointerfaces 112 through the allocation, release, and handover of radiotransmission channels.

The radio controller 302 may carry out various procedures that relate tocall connection tasks. For example, the radio controller 302 may beresponsible for system information broadcasting, subscriber paging,immediate traffic channel assignment, subsequent traffic channelassignment, call handover, radio connection and release, connectionfailure detection and reporting, and power capability indicationreporting. One example of a radio controller 302 is a base stationcontroller (BSC).

The switching center 304 coordinates the allocation and routing of callsinvolving subscriber units 110 by, among other things, receiving dialeddigits, interpreting call processing tones and providing routing paths.For example, the switching center 304 is operable to process a servicerequest from a subscriber terminal 110 and route a corresponding call tothe designated switched network 106, a mobile network 104 or to anothersubscriber terminal 110. Similarly, the switching center 304 is operableto process a service request from a mobile network 104 or switchednetwork 106 and route a corresponding call to a designated subscriberunit 110. The switching center is primarily responsible for mobilitymanagement, call control and trunking, such as coordinating the settingup and termination of calls to and from subscriber terminals 110.Additionally, it provides all of the functionality needed to handlemobile subscriber units 110 through location updating, handover and calldelivery.

The software architecture of the telecommunications system 100 ispreferably based on object-oriented software engineering technology, andthe use of managed objects provided within the network management system204 and the call processor assembly 200. Managed objects are provided tosupport system logical attributes and administrative functions. Managedobjects model the various functional, hardware, and interface componentsand sub- components associated with the telecommunications system 100.Such software may also model the functional procedures performed byphysical components. Managed objects can be created, modified, anddeleted by an operator, for example via the network management system204.

FIG. 2 illustrates agent groups 2010-2050 connected to a translator androuter 2000 according to an exemplary embodiment of the presentinvention. As shown in FIG. 2, agent groups 2010-2050 include, forexample, mobile connection group 2010, gateway group 2020, R2 group2030, ISUP group 2040 and TUP group 2050. R2 group 2030, ISUP group 2040and TUP group 2050 can also be referred to as trunk groups. Each groupincludes agents with the same characteristics. For example, the mobileconnection group 2010 includes mobile agents 2011 so that there is amobile agent 2011 for each dedicated connection between a subscriberterminal 110 and the mobile network (e.g., one agent represents one callhalf). Similarly, gateway group 2020 includes gateway agents 2021, R2group 2030 includes R2 agents 2031, ISUP group 2040 includes ISUP agents2041 and TUP group 2050 includes TUP agents 2051. Agent groups couldalso be provided for any other desired operation, such as, for example,loop backs (e.g., for testing), test tones, test announcements andrecord announcements.

According to an exemplary embodiment of the present invention, thefollowing call processing architecture is used to build a call, e.g.,establish a call connection. With reference to FIGS. 1 and 2, a call isoriginated on a PLMN 104, PSTN 106 or by a subscriber terminal 110. Thecall is initiated by, for example, the calling party entering the dialeddigits for the called party. The call connection is established byconnecting a protocol (e.g., state) machine for the calling party (e.g.,a MSC for a PLMN or a switching center for a PSTN) with a protocolmachine for the called party. According to an embodiment of the presentinvention, the call connection is treated as having two halves—anoriginating half and a terminating half. Each call half is associatedwith an agent group and an agent of the agent group.

Agent groups and agents are illustrated in FIG. 2. An agent, such as amobile agent 2011 or an ISUP agent 2041 is, for example, a softwareentity that provides a call state machine for a particular call type(e.g., mobile, ISUP or R2). Each agent, which can function as anoriginating agent, a terminating agent or both, has, for example, anexternal interface and an internal interface. The internal interfaceprovides the ability to communicate with another agcnt or elements ofthe telecommunications system while the external interface allowscommunication using the native protocol call messages for the particularcall type (e.g., mobile, ISUP, R2, etc.). Thus, the internal interfaceof each agent includes the capability to convert between the nativeprotocol call message format and the call message format of otheragents. An agent could also include the capability of converting betweenits unique signaling format (e.g., native protocol) and a standardformat as described in detail below regarding an agent interworkingprotocol according to an embodiment of the present invention. Thefunctions performed by each agent include, for example, call setup, callprocessing and call termination. An agent group is also, for example, asoftware entity that represents a collection of agents of the same type,as illustrated in FIG. 2. As explained in more detail below, an agentgroup has its own behavior which includes, for example, selecting agentsfor establishing call connections when requested and registering theagent group with a translator and router so that the agent group can beused to route calls, also as described below.

In an embodiment of the present invention, agents follow a set of basicrules in establishing a call connection. For example, each agentinteracts with a translator and router to process the dialed digits fora call (generally referred to as translation, although modification ofthe dialed digits is not always required) and determine a route forestablishing a connection with a terminating aoent. According to anexemplary embodiment of the present invention, a translator and router,for example indicated as 2000 in FIG. 2, helps isolate an originatingagent (e.g., the agent handling the originating half of the call) fromthe responsibilities of obtaining a terminating agent (e.g., the agenthandling the terminating half of the call). The translator and router2000 facilitates the selection of a terminating agent via interactionwith the originating agent. For example, upon receipt of the dialeddigits, the originating agent can make a translation request to thetranslator and router 2000 to perform any processing of the dialeddigits required by the telecommunications system. Another request can bemade by the originating agent to the translator and router 2000 that theprocessed digits be used to identify a route for completing the callconnection. Thus, the translator and router 2000 can use the processeddigits to determine a route by, for example, determining the agent groupassociated with the processed dialed digits and requesting that theagent group identify an idle agent to serve as a terminating agent forthe call, an ID being provided to the originating agent and theterminating agent to identify a connection path between the originatingand terminating agents.

Thus, in the call processing architecture according to an embodiment ofthe present invention, upon a call attempt, an originating agent isallocated by the switching center of the telecommunication system andthe originating agent receives the dialed digits via its externalinterface. The originating agent then sends a translate request to atranslator and router and in response receives an acknowledgment messageand the results of the request (e.g., the processed dialed digits). Theprocessed dialed digits are generated, for example, via translationtables in the translator and router described in more detail below. Theoriginating agent then sends a route request to the translator androuter along with the processed dialed digits and a connector ID. Theconnector ID represents, for example, a software entity for acommunication path between the originating and terminating agents. Inresponse to the route request, the translator and router determines aroute (e.g., the agent group for the terminating agent) via, forexample, a routing table in the translator and router, described in moredetail below.

The translator and router then sends a request to the identified agentgroup that an idle agent be identified for completing the callconnection. The connector ID from the originating agent is also providedto the agent group identifying a connection path between the originatingand terminating agents. While the connector ID is determined by theoriginating agent the translator and router or the terminating agentcould also allocate the connector ID. The agent group polls its pool ofagents and if an idle agent is found, an acknowledgment message isreturned to the translator and router and also forwarded to theoriginating agent. The connector ID is provided to the terminating agentby the terminating agent group. Thus, the originating agent can nowcomplete its connection with the terminating agent to allow dialoguebetween the agents and also tear down of the call connection attermination of the call via the allocated connection path. If theterminating agent determines that the call needs another type of agent(e.g., due to redirection, call forwarding, etc.), the terminating agentcan also act as an originating agent and, through the same actionsdescribed above, interact with the translator and router to identify thenext agent needed to process the call, all of the agents being connecteduntil the call is setup. Thus. the call processing architectureaccording to the present invention allows call connections to be builtby connecting agents for each half of a call connection, allowingmultiple agents to be connected together if necessary until the callconnection is established.

In an embodiment of the present invention, mobile agents 2011 areresponsible for establishing a mobile originated or mobile terminatingconnection between the switching center 304 and a subscriber terminal110. Accordingly, mobile agents 2011 communicate with the MobileApplication Part (MAP) protocol which addresses registration andhand-off of subscriber terminals. Mobile agents 2011 are alsoresponsible for interworking with a second agent in the role of calloriginator or terminator. R2 agents 2031 are responsible forestablishing a connection between the switching center 304 and a PSTNusing the R2 protocol and also interworking with another agent in therole of call originator or terminator. Gateway agents 2021 areresponsible for routing calls destined for subscriber terminals 110(e.g., mobile network calls). For example, if the destination subscriberterminal 110 is visiting the gateway agent's switching center, the callwill be routed to a mobile agent 2011. However, if the destinationsubscriber terminal 110 is currently visiting a switching center otherthan the gateway agent's switching center, then the call will be routedto a trunk agent, such as a R2 agent 2031. ISUP agent 2041 or TUP agent2051 to connect the call to the mobile network servicing the destinationsubscriber terminal 110. ISUP agents 2041 are responsible forestablishing a connection between the switching center 304 and the PSTNusing, for example, the ITU White Book ISUP protocol or the ETSI V2 ISUPprotocol and also interworking with another agent in the role of calloriginator or terminator.

Like the agents 2011-2051 which are implemented as software objects inthe switching center 304, the translator and router 2000 can also beimplemented in software in the switching center 304, for example as asoftware object. The translator and router 2000 manages all the calltranslations and routing functions for the agents. As is known in theart, when a subscriber terminal 110 originates a call, the subscriberterminal's dialed number is transferred, as it is dialed, to thetelecommunications system 100. A translation process, implemented in thetranslation and router 2000, converts the dialed number into agenerically formatted telephone number. The translation process mayinclude, for example, the prefixing of (e.g., stripping off) area code,long distance or international codes, conversion of service codes (e.g.411 or 911) into telephone numbers or any other mapping/formattingaction decided by the operator of the telecommunication system 100. Thedialed number may also pass untranslated through the translator androuter 2000. After translation, the router function of the translatorand router 2000 routes the translated number towards the correctdestination. The router function utilizes routing tables to map atranslated number to a route list that contains an ordered list ofroutes. Routes correspond to agent groups, for example, trunk groupnames, subscriber terminal terminations, call delivery features or testcircuits. The destination may be, for example, a specific outgoing trunkgroup directed to a PSTN or to a voice mail system or to anothersubscriber terminal 110 serviced by the telecommunications system 100.For a call terminating at a subscriber terminal 110, once the callarrives at the switching center 304 servicing the subscriber terminal110, no translation or routing is necessary and the call is set up tothe subscriber terminal 110.

The translator and router 2000 includes, for example, a translatorsubtable with translator entries and a router subtable with routerentries. Translation and routing tables are generally different for eachtype of agent, e.g., each agent group and its associated agents utilizeparticular translation and routing tables distinct from the tablesutilized by other agent groups. The translation and routing tablesfunction to check received digits in a number to modify received digitswhen required, and to select available routing agents to connect a call.The table can be for example, subfunctions of a Translator/Router objectmodel for an object oriented implementation of the translator and router2000 in the switching center 304.

A translator subtable represents a table of translator entries and isused for manipulating incoming or outgoing digits. For example, numbertranslation tables can contain entries to strip prefix digits (e.g., 0,1, 01 or 011 ) from a number, append an area code to a local directorynumber or map a service code (e.g., 411 or 911) to a local number.Incoming translation tables modify digits to obtain a pattern that willbe recognized by the routing function, thus allowing selection of anagent to connect the call. Outgoing translation tables apply to trunkgroups only and modify digits to obtain a pattern that will becompatible with the receive digits register in the destination switch.For example, if a destination switch requires a number in a specificformat, then outgoing translations can be used to manipulate the numberbefore it is sent to the destination switch. Thus, if the destinationexchange requires 1+10 digits, the outgoing translation tables can beused to prefix the “1” in front of the 10 digits.

A translation subtable contains, for example, one or more translationentries, each entry being composed of a MATCH digit pattern and a MODIFYdigit pattern. The match pattern is used to match the digits totranslate. If a match occurs, then the digits are modified based on themodify pattern. If no match occurs, then the received digits are usedand passed on to the router function. The router subtable represents atable of router entries and is used for routing an incoming call. Aroute subtable contains, for example, one or more routing entries, eachentry being composed of a MATCH digit pattern and a ROUTE LIST. TheROUTE LIST identifies one or more agent group names, as described below.Thus, each router entry represents a MATCH digit pattern used to matchthe processed dialed digits from the translation to the route (e.g., theagent group) which processes the called number. An exemplary translationtable and routing table are shown below.

Translation Table MATCH MODIFY ENTRY1 0??????? 901??????? ENTRY21??????? 901??????? ENTRY3 0?????????? ?????????? ENTRY4 1????????????????????

Routing Table MATCH ROUTE LIST ENTRY1 901??????? TRKGRP1 ENTRY2902??????? TRKGRP2 ENTRY3 77275555555 GSM ENTRY4 ?????????? TRKGRP1TRKGRP2

FIG. 6 illustrates an exemplary flow diagram of a call processingarchitecture in accordance with an embodiment of the present invention.A switching center of a telecommunications network such as a mobileswitching center 304 receives a digit sequence from a calling party instep 1000 and an originating agent is assigned in step 1001. Dependingon the originating location of the call, (e.g., PLMN or PSTN) theassigned agent could be, for example, a mobile agent 2011, an ISUP agent2041 or an R2 agent 2031. A translation request is made by theoriginating agent to a translator and router in step 1002. The receiveddigit sequence is translated by use of, for example, an incomingtranslation index in the translator and router of the switching center304 in steps 1003-1005. The incoming translation index (e.g.,translation table) includes one or more entries, each entry of theincoming translation index including a digit pattern, which is comparedand matched to the dialed digit sequence, and a corresponding modifieddigit pattern, which is used to modify the dialed digit sequence. Theincoming translation index first compares the received dialed digitsequence with the various digit pattern entries at step 1003. Theincoming translation index then determines whether the received digitsequence matches a digit pattern included in an entry of the incomingtranslation index at step 1004. If there is a match, then the receiveddigit sequence is modified in accordance with the corresponding modifieddigit pattern (that is, the modified digit pattern of the entry thatincluded the digit pattern which matched the received digit sequence),at step 1005. If there is no match, however, then the received digitpattern is not modified.

The processed dialed digits are returned to the originating agent,whether or not modified by the incoming translation index, and then aroute request is made by the originating agent to the translator androuter in step 1006. A route translation index (e.g., routing table) inthe translator and router includes one or more entries, each entry ofthe incoming translation index including a digit pattern, which iscompared and matched to the processed digit sequence, and acorresponding route list, which is used to route the call within thetelecommunications system 100. Like the incoming translation index, theincoming route index first compares the processed digit pattern, whethermodified or not, with the various entries contained in that route indexat step 1007. The incoming route index then determines whether thereceived digit sequence matches a digit pattern of an entry of theincoming route index at step 1008. If there is a match, then the routelist corresponding with that digit pattern is identified at step 1009.The translator and router then sends a message to the agent groupidentified in the route list requesting that an idle agent be providedin step 1001. For example, a trunk group may be identified by the routelist for a call that is to terminate to a switched network, whereas agateway group may be identified by the route list for a call that is toterminate to a subscriber unit 110. If there is no match for theprocessed digits, however, then an appropriate signal is sent to thenetwork that originated the call, as provided at step 1008. The agentgroup polls its group of agents to determine if there is an idle agentand if an idle agent is found, the originating connector ID is passed tothe terminating agent group and subsequently to the terminating agent,thereby establishing the communication path between the originating andterminating agent. The call connection between the originating agent andthe terminating agent is via the connection path and is established instep 1013. The connection path can support the transmission of theunique protocol needed by each agent (e.g., as is known in the art, theoriginating agent converts its unique protocol to the protocol of theterminating agent) or the transmission of a standard protocol used tocommunicate between agents, such as an agent interworking protocolaccording to an embodiment of the present invention described below.

Call origination and termination using the call processing architectureaccording to an embodiment of the present invention as well as an agentinterworking protocol according to an embodiment of the presentinvention operates as follows, although the agent interworking protocolis not necessary in order carry out the call processing architectureaccording to an embodiment of the present invention, as any known methodof establishing communication between agents could be used with the callprocessing architecture of the present invention.

Assume a telephone call between a subscriber unit 110 and a called partyconnected to a PSTN, as illustrated in FIG. 4. When the subscriber unit110 initiates the call, the subscriber unit 110 transmits a call requestsignal (e.g., the digits dialed by the calling party) and is connectedto the radio controller 302 which is in turn connected to the switchingcenter 304, as illustrated in FIG. 1. Upon receiving the call requestsignal from the subscriber unit 110, a mobile agent 2011 residing in theswitching center 304 is selected by the switching center 304 andestablishes the mobile network connection with the subscriber unit 110.For example, the mobile agent 2011 will receive the dialed digits in theunique mobile agent protocol via its external interface and will conductthe mobile network call setup including the assignment of trafficchannels. The mobile agent 2011 is now the originating agent.

The mobile agent 2011 sends, for example, a translation request to thetranslator and router 2000, the translation request including, forexample, the dialed number and a translation table index from, forexample, an index field of the switching center 304. For example, thetranslation table index identifies the appropriate translation subtableto use. In the translator and router 2000, a translation subtable isfound using the translation table index and the dialed number is indexedinto the translation subtable and modified accordingly into a translatednumber as explained above. For example, the MATCH entries of thetranslation table are read and if a MATCH is found, the correspondingMODIFY digits are passed back to the originating agent 2011. If thedialed number is not in the subtable, then the translated number is thesame as the dialed number. A translate response message is then returnedby the translator and router 2000 to the mobile agent 2011 including thetranslated (e.g., processed) number.

The mobile agent 2011 then sends a routingy request to the translatorand router 2000 including the translated number, the connector ID and aroute table index from a routing index field of the switching center304. For example, the routing index field identifies the appropriaterouting subtable to use. The route subtable is found using the routetable index. The translator and router 2000 then indexes the translatednumber into the route subtable and the route list is obtained asexplained above. For example, the MATCH entries of the route table areread and if a MATCH is found for the translated number, thecorresponding ROUTE LIST is used to select a terminating agent group. Asa result of identifying the call destination, in this example destinedfor a PSTN, the translator and router 2000 sends a select requestmessage including the connector ID to the ISUP trunk group 2040 that anidle ISUP agent 2041 be identified. The ISUP trunk group 2040 polls itspool of ISUP agents 2041 and if an idle agent 2041 is found, indicatedby a select ACK message, then a connector reference (e.g., AIP referenceor ID) is provided to the idle agent. Then a connection is establishedbetween the originating and terminating agents. The AIP connector (e.g.a software object with a connector portion and a termination portion)represents the software entity connecting the originating andterminating agents and passes generic AIP messaging between two agentsto facilitate communication between the agents. As illustrated in FIG.2, the translator and router 2000 is the central hub for the agentswhich are connected to the hub.

If the processed digits are not in the route subtable then, for example,a route nack message is returned to the mobile agent 2011 indicatingthat there is no route to the destination. If an idle agent 2041 is notavailable, then a select nack message is returned by the ISUP agentgroup 2040 indicating that no circuit is available. If an idle agent2041 is available, however, the translator and router 2000 then returnsa route ack message to the originating agent including the route name(e.g., the agent group name) and the AIP reference as described above.

An exemplary flow of messages utilizing the AIP connector according toan embodiment of the present invention is illustrated in FIG. 3. Asshown in FIG. 3, all of the messages pass through the AIP according toan embodiment of the present invention. The SETUP messages contain thecalled number and are used to initiate call termination with the callednumber.

The SETUP ACK messages represent an acknowledgment that call terminationwith the called party is proceeding. ALERTING messages are used toindicate that the far end (e.g., the called party's network) hascommenced establishing the call termination. The ANSWER messagesindicate that the far end has answered the call. The RELEASE messagesindicate that the near end (e.g., the calling party) or the far end hasreleased the call connection.

Once the originating and terminating agents are connected via the AIPconnection, call setup messaging can be communicated between the agentsby the originating agent converting the format of its call setupmessages to the AIP and the terminating agent receiving the AIPformatted messages and converting the AIP messages to the terminatingagent's format. Thus, for example, in the above example, a mobileoriginating agent 2011 converts the mobile formatted messages to the AIPand an ISUP terminating agent 2041 converts the AIP formatted messagesto ISUP formatted messages. For example, the native protocol for eachcall type is defined by industry standards and includes message fieldsthat can be mapped to, for example the appropriate exemplary fields ofthe AIP according to the present invention described below. As isobvious to those skilled in the art, the particular implementation of anagent interworking protocol (AIP) can vary as long as each agentcontains the capability of converting to and from a standard protocol,referred to here as AIP. Further, in an object oriented implementationof the present invention, the native protocols for each agent as well asa generic protocol can be stored in a memory of for example a switchingcenter as objects. The objects include, for example, the call messagesfor each protocol. A translation object could also be stored in thememory of the switching center to provide, for each agent, the mappingof messages between the native protocol for the agent and the genericprotocol. An exemplary protocol definition for the AIP is set forthbelow, although varying implementations of the AIP accomplishing thefunction of a generic protocol used to establish, maintain and release aconnection between two call processing agents are within the scope ofthe present invention.

The AIP according to an embodiment of the present invention includesseveral types of messages. Each message element can use, for example,instances of ObjecTime case tool data types, although any structureconsisting of data elements could be used. For example, most messageelements are instances of a basic type such as Integer and String. Othermessagje elements are instances of a grouping of the basic data types oruser defined enumerated types described in detail below. Each messageelement can be optional (O) or mandatory (M). For example, the aipSetupmessage is used to initiate a dialog between two call processing agents.It is sent from originator agent to terminator agent and includes, forexample, the following message elements illustrated in Table 1.

TABLE 1 ME Type Presence route STRING M cdrId INTEGER O connId INTEGER OtrunkGroupID INTEGER O cellid MSCCellIdentity O cpc INTEGER O continuityINTEGER O echoControl MSCEchoControl O ss7Interworking INTEGER OcalledPartyAddress MSCGsmNumber O callingPartyAddress MSCGsmCallingNum OoriginalCalledPartyAddress MSCGsmOrigCalledNum O redirectingPartyAddressMSCGsmRedirectingNum O satellite INTEGER O redirInfo MSCGsmRedirInfo O

The exemplary message elements (ME) shown in Table 1 are described asfollows. The callingPartyAddress message element is to identify thecalling party. The route message element is to identify the agent groupof the originator agent. The cdrId message element is to identify theCall Data Record ID of the originator agent. The connId message elementis to identify the switching matrix connection for the call. The cellidmessage element is to identify the cell in which the traffic channel wasassigned. It is provided, for example, if the originator agent isprocessing an emergency call.

The cpc message element contains the Calling Party Category. This fieldis used by GSM and ISUP agents. The satellite message element is toidentify if one or more satellites are involved in the current call.This is important to know because the delay caused by satellite linksaffects the overall quality of calls and therefore, when possible,multiple satellite hops are avoided. The continuity message eletment isto pass information about the status of SS7 continuity checking for thecurrent call. If Continuity is not supported, then this message elementwill always have the default value of‘contNotRequired’. The echoControlmessage element is to pass information about whether echo devices arealready included in a call or need to be inserted in certain situations.If Echo Control is not supported, this message would have the defaultvalue of ‘ogEchoDevNotIncluded’. The ss7Interworking message element isto pass information about whether the call is all ss7 or whether PSTNinterworking (R1, R2, etc.) has occurred.

The calledPartyAddress message element is to pass information about thedialed number including the numbering plan and whether the number isnational, international, etc. The callingPartyAddress message element isto pass information about the calling party such as the calling line ID,whether the caller restricts or allows his CLID to be presented. TheoriginalCalledPartyAddress message element is to pass information aboutthe number that a caller was attempting to reach before forwardingredirected the call elsewhere. Information contained includes, forexample, the original number that was called and whether that originalcalled party allows his (forwarding) number to be displayed to theforwarded to party. An example use of this information is the situationwhere multiple people have forwarded phones to the same number. Seeingthe original called party as well as the calling party on certaindisplays can tell not only who is calling, but which of the partiesforwarded to this one phone the caller was trying to reach. TheredirectingPartyAddress message element is to pass the information aboutthe forwarding party in a call. Example fields are the forwardingparty's number and whether the forwarding party allows or restricts hisnumber from being displayed. If only one forwarding occurs in a call,this number will be the same as the original called number, but ifmultiple forwardings occur, this number will be that of the lastforwarding party. An example use of this field is to ensure that if acaller attempts to call a local number that has been forwarded overlong-distance, the forwarding party will be charged for the longdistance call rather than the calling party that was only trying to makea local call. The redirInfo message element is to pass relevantinformation about the history of the forwarding of a call (while theredirectingPartyInfo element only has information about the lastforwarding, party). Example fields include the number of forwardingsdone in the call, the original forwarding reason, the last forwardingreason, and certain presentation/restriction information.

Another type of message in an exemplary AIP according to an embodimentof the present invention is the aipSetupAck Message. The aipSetupAckmessage is used to acknowledge receipt of the aipSetup message andprovide information about the terminator agent. It is sent from theterminator agent to the originator agent. Exemplary message elements fora SetupAck Message is shown in Table 2.

TABLE 2 ME Type Presence applyRingback BOOLEAN M route STRING MbackwardSetupInfo MSCGsmBackSetupInfo O eventInfo MSCGsmEventInfo O

The exemplary message elements (ME) shown in Table 2 are described asfollows. The applyRingback message element is to tell whether the switchelement 304 (e.g., MSC) needs to connect a ringback tone to theoriginating agent while the MSC attempts to reach the terminating party.It is set whenever the MSC is the terminating office in a call. Theroute message element is to identify the agent group of the terminatingagent. The backwardSetupInfo message element is to pass information backto the originator agent that SS7 exchanges can use to determine how acall should be set up and what facilities are involved. The eventInfomessage element is to pass information backwards toward the originatorof the call such as whether the terminator is being rung or ifforwarding has occurred (and if so what type of forwarding hasoccurred).

Another type of message in the AIP according to an embodiment of thepresent invention is an aipAlerting Message. The aipAlerting messageinforms the originator agent that the called party's telephone isringing. It is sent from the terminator agent to the originator agent.Exemplary message elements of the aipAlerting, message are shown inTable 3.

TABLE 3 ME Type Presence backwardSetupInfo MSCGsmBackSetupInfo OeventInfo MSCGsmEventInfo O

The backwardSetupInfo message element is to pass information back to theoriginator agent that SS7 exchanges can use to determine how a callshould be set up and what facilities are involved. The eventInfo messageelement is to pass information backwards toward the originator of thecall such as whether the terminator is being rung or if forwarding hasoccurred (and if so what type of forwarding has occurred), and whetherinformation may be presented to the originator.

Another type of message in the AIP according to an embodiment of thepresent invention is an aipAnswer Message. The aipAnswer message informsthe originating agent that the called party has received/accepted thecall. It is sent from the terminating agent to the originating agent. Anexemplary message element of the aipAlerting message is shown in Table4.

TABLE 4 ME Type Presence backwardSetupInfo MSCGsmBackSetupInfo O

The backwardSetupInfo message element is to pass information back to theoriginator that SS7 exchanges can use to determine how a call should beset up and what facilities are involved.

Another type of message in the AIP according to an embodiment of thepresent invention is an aipPlayTone Message. The aipPlayTone messageinforms the receiver that the sender has requested the application of aDTMF tone at the receiving end. An exemplary message element of theaipPlayTone message is shown in Table 5.

TABLE 5 ME Type Presence tone INTEGER M

The tone message element specifics which DTMF tone should be applied.

Another exemplary message of an AIP according to an embodiment of thepresent invention is an aipStopTone Message. The aipStopTone messageinforms the receiver that the sender has requested the termination of aDTMF tone at the receiving end. The aipStopTone message will always bepreceded by an aipPlayTone message. There are no message elements inthis message.

Another exemplary message of an AIP according to an embodiment of thepresent invention is an aipRelease Message. The aipRelease messageinforms the receiver that the dialog has been terminated by the sender.It can be sent by either the originator or terminator. No reply to thismessage is expected or should be sent. Exemplary message elements of theaipRelease message are shown in Table 6.

TABLE 6 ME Type Presence cause INTEGER M meteringPulses INTEGER Olocation INTEGER O disconnectingParty INTEGER O

The cause message element is to provide the reason why the dialog wasterminated. The meteringPulses message element is to provide the numberof meter pulses received from the superior exchange for the call. Thelocation message element is to provide the location at the network levelof the initiator of the dialog release. The disconnectingParty messageelement indicates whether the calling party, called party or networkreleased the call.

Another exemplary message element of an AIP according to an embodimentof the present invention is an aipRetry message. The aipRetry messagehas, for example, one element, cause. The cause message element is sentby the terminator trunk to the originator during glare conditions (e.g.,attempt to access both paths of a bi-directional bus simultaneously) ora seize failure condition. The cause message element indicates thereason for the failure. Upon receipt of the cause message by theoriginating agent, the originating agent retries call routing. The AIPaccording to an embodiment of the present invention can also includeuser defined message element types. All message elements can use, forexample, instances of ObjecTime data types. Most are instances of abasic ObjecTime data types such as INTEGER and STRING, as illustrated inthe above tables. Others are instances of a grouping of the basicObjecTime data types or user defined enumerated types, also asillustrated in the above tables. The type definitions below show theuser defined type used in some of the messages above.

MSCCellIdentity Type Sub-Element Type Presence mcc STRING M mnc STRING Mlac INTEGER M cid INTEGER M

The mcc sub-element is to specify the Mobile Country Code. The mncsub-element is to specify the Mobile Network Code. The lac sub-elementis to specify the Location Area Code. The cid sub-element is to specifythe Cell Identifier.

MSCGsmNumber Type Sub-Element Type Presence digits STRING M ton INTEGERM npi INTEGER M

The digits field is to carry an address. The ton (type of number)message element is to give information associated with an addressindicating the nature of the number. For example, the number could be aninternational number, a national number, or an ISDN subscriber number.The npi (numbering plan identifier) message element is to give theassociated specification used to determine the meaning of the numbers inan address. Examples are the ISUP numbering plan defined in ITU E.164and the Data Numbering Plan defined in ITU X.121.

MSCGsmCallingNum Type Sub-Element Type Presence digits STRING M tonINTEGER M npi INTEGER M ni INTEGER M pi INTEGER M

The digits field is to carry the address of the originating (calling)party in this call. The ton (type of number) message element is to giveinformation associated with an address indicating the nature of thenumber. For example, the number could be an international number, anational number, or an ISDN subscriber number. The npi (numbering planidentifier) message element is to give the associated specification usedto determine the meaning of the numbers in an address. Examples are theISUP numbering plan defined in ITU E.164 and the Data Numbering Plandefined in ITU X.121. The ni (number incomplete) message element is totell that though a calling address is included, it is not the completecalling party address. The pi (presentation indicator) message elementis to tell whether the address information may be presented to an enduser for potential display on a calling line ID device.

MSCGsmOrigCalledNum Type Sub-Element Type Presence digits STRING M tonINTEGER M npi INTEGER M pi INTEGER M

The purpose of the address digits here is to give the identity of theoriginal party that the caller wished to reach before any forwardingoccurred. The ton (type of number) message element is to giveinformation associated with an address indicating the nature of thenumber. For example, the number could be an international number, anational number, or an ISDN subscriber number. The npi (numbering planidentifier) message element is to give the associated specification usedto determine the meaning of the numbers in an address. Examples are theISUP numbering plan defined in ITU E.164 and the Data Numbering Plandefined in ITU X.121. The pi (presentation indicator) message element isto tell whether the address information may be presented to an end userfor potential display on a calling line ID device.

MSCGsmRedirectingNum Type Sub-Element Type Presence digits STRING M tonINTEGER M npi INTEGER M pi INTEGER M

The purpose of the address digits here is to give the identity of thelast party that forwarded the call. If only one forwarding occurs thiswill be the same as the original called party address. The ton (type ofnumber) message element is to give information associated with anaddress indicating the nature of the number. For example, the numbercould be an international number, a national number, or an ISDNsubscriber number. The npi (numbering plan identifier) message elementis to give the associated specification used to determine the meaning ofthe numbers in an address. Examples are the ISUP numbering plan definedin ITU E.164 and the Data Numbering Plan defined in ITU X.121. The pi(presentation indicator) message element is to tell whether the addressinformation may be presented to an end user for potential display on acalling line ID device.

MSCGsmRedirInfo Type Sub-Element Type Presence redirectingInd INTEGER MorigRedirReason INTEGER M redirCounter INTEGER M redirReason INTEGER M

The redirectingInd message element is to tell whether the call has beenforwarded or rerouted and whether or not presentation of redirectioninformation to the calling party is restricted. The origRedirReasonmessage element is to tell the reason the call was originallyredirected. The redirCounter message element is to indicate the numberof redirections which have occurred on a call. The redirReason messageelement is to tell, in the case of a call undergoing multipleredirections, the reason why the last redirection has occurred.

MSCGsmBackSetupInfo Type Sub-ELement Type Presence chargeInfo INTEGER McalledPtyStatus INTEGER M ss7Integerworking INTEGER M echoControlMSCEchoControl M

The MSCGsmBackSetupInfo type is passed from terminator to originator toindicate the facilities involved in the call setup, e.g., echocancellers, SS7 interworking or charging. The chargeInfo message elementis to tell whether or not the call is chargeable. The calledPtyStatusmessage element is to tell the state of the called party. For example,‘subscriber free’ if the called party is not on a call. Thess7interworking message element is to tell whether or not SS7 is used inall parts of the network connection. The echoControl message element isto pass information about whether echo devices are already included in acall or need to be inserted in certain situations. If Echo Control isnot supported, then this message element will have the default value of‘icEchoDevNotIncluded’.

MSCGsmEventInfo Type Sub-Element Type Presence eventInd INTEGER MeventPresentation INTEGER M

The eventInd message element is to give more information about thereason that an aipSetupAck or aipAlerting message has been sent (e.g.,to communicate call event information). For example, two reasons thesemessages are sent are to show further progress in the call or to tellthat alerting is occurring. This message element could also passinformation about the reason a call was forwarded. The eventPresentationmessage element is to glve more information about whether informationabout the progress of the call can be displayed back to the originatorof the call. This field can be set true if the forwarding options fromeventInd (which may not be used) are the situations in whicheventPresentation might be restricted. An example of possible future useis a user could restrict presentation of event information so that theoriginator could not tell if the call had been forwarded or not.

MSCEchoControl Type Sub-Element Type Presence enabled BOOLEAN M infoINTEGER M erl INTEGER M

The enabled message element is to pass information about whether aper-trunk echo cancellor is enabled for a specific call. This fieldgives information only about whether local echo control is on. The infofield gives information about whether echo control is being doneanywhere in the call (even on other switches). The info message elementis to pass information about whether echo control has already been setat the originator or terminator of a call. This information is importantbecause on long calls, if info about whether echo is set or not is notincluded, then too many or too few echo cancellors may be inserted intothe call. The erl (echo return loss) field contains an estimate of theloss associated with echo in this call. The value is taken from thetrunk information stored in the OAM server and entered through the NMS.This field is used, for example, to train the echo cancellor.

Another example of the operation of the AIP according to the presentinvention is a mobile to mobile call. e.g., from a first subscriberterminal 110 to a second subscriber terminal 110 on telecommunicationsnetwork 100, as shown in FIG. 5. When the first subscriber terminal 110originates the call, the dialed digits are received at the switchingcenter 304 and the switching center 304 assigns a mobile agent 2011 toset up the originating half of the call between the first mobilesubscriber 110 and the switching center 304. The mobile agent 2011 sendsa translation request to the translator and router 2000 along with atranslation table index. The translator and router 2000 reads the MATCHentries of the appropriate translation table and if a MATCH is found,the corresponding MODIFY digit pattern is returned to the mobile agent2011, which then sends a routing request to the translator and router2000 along with a routing table index. The translator and router readsthe MATCH entries of the appropriate route table and if a MATCH isfound, the ROUTE LIST is used to select an agent group and an idleagent, in this case gateway agent 2021 (e.g., the agent used to connectto another subscriber terminal 110). As described earlier, the selectionof a gateway agent 2021 includes the provision of an AIP referencenumber from the originating agent identifying the connection path thatestablishes the link between mobile agent 2011 (the originating agent)and gateway agent 2021 (the terminating agent). Gateway agent 2021,using the incoming translated digits from the mobile agent 2011,accesses the home location register (HLR) 504 of the telecommunicationssystem 100 to determine the location of the second subscriber terminal110. As is known in the art, HLR 504 contains the administrativeinformation associated with each subscriber terminal 110 registered inthe telecommunications system 100 along with the current location ofeach subscriber terminal 110.

The HLR 504 may return the same or a different digit string depending onthe location of the second subscriber terminal (e.g., in the network orroaming outside of the network). Using the digit string received fromthe HLR 504, the gateway agent 2021 (now acting as an originating agent)sends a translation request and a translation table index to thetranslator and router 2000 to translate the digit pattern. If a MATCH isfound, the translated digit pattern is returned to the gateway agent2021 and a routing requiest and route table index are sent to thetranslator and router 2000 to determine if there is a MATCH andcorresponding ROUTE LIST for the translated digits. Since the call inthis example is to a subscriber terminal 110, the ROUTE LIST in theroute subtable must include a mobile agent group 2010 (e.g., GSM), whichis a pool of mobile connections (e.g., mobile agents 2011) via radiochannels. In addition to identifying the mobile agent group 2010 to thegateway agent 2021 (now the originating agent), the gateway agent 2021will provide an an AIP reference number for the AIP connection path forcommunication between the gateway agent 2021 and the new terminatingagent, in this case a second mobile agent 2011, to complete theconnection of the call from the first subscriber terminal 110 to thesecond subscriber terminal 110.

As is evident from this example, using the AIP according to anembodiment of the present invention allows agents, such as the gatewayagent 2021, to communicate with the HLR 504 using the native MAPprotocol required to interface with the HLR (via the external interfaceof agent 2021) and also to communicate with all other agents using AIP(via the internal interface of agent 2021). Further, the use of ageneric call message protocol to connect agents allows new agents (e.g.,for new call types) to be easily added to the telecommunications systemas no integration problems arise due to the generic interface protocolbetween all agents, whether new or existing.

If in the above example a call forwarding feature was activated by thesecond subscriber terminal 110 a daisy chain of AIP connections betweenagents would result, in contrast the operation of conventionalcommunication systems. For example, in conventional communicationsystems, each agent is required to perform complex tasks in a callforwarding situation such as evaluating the downstream situation andtaking appropriate action such as breaking down the existing connectionand establishing a new connection to get to the desired destination. Incontrast, using the AIP connection between agents according to anembodiment of the present invention allows agents to be easily connectedin a daisy chain until the destination agent is reached withoutrequiring complicated tasks be performed by each agent other thanconversion between the AIP and an agent's native protocol.

For example, according to an embodiment of the present invention, thefirst mobile agent 2011 and the gateway agent 2021 in the previousexample would be connected via an AIP connection, and the gateway agent2021 and the second mobile agent 2011 would be connected by a separateAIP connection. If the second mobile agent 2011 determined that callforwarding was activated for the second subscriber terminal 110 or thatthe call needed to be redirected for any reason, then, in the samemanner described in detail above via interaction with the translator androuter 2000, the second mobile agent 2011 would obtain an AIP connectionwith the agent responsible for establishing the connection with theforwarded number, which could be another subscriber terminal 110invoking a third mobile agent 2011 or a network connection requiring oneor more IUSP, TUP or R2 agents to complete the call, as shown in FIG. 5.Thus, a chain of agents can be daisy-chained together using the AIPprotocol thereby providing an elegant building block concept forhandling call forwarding not provided by conventional communicationsystems that also reduces the processing capabilities required by eachagent. As noted earlier, using the AIP according to an embodiment of thepresent invention is not required to practice the call processingarchitecture according to the present invention and could be used withother call processing architectures, but does provide a furtherimprovement on the operation of the call processing architectureaccording to the present invention.

What is claimed is:
 1. A method for establishing a call connection, comprising the steps of: receiving a call request signal from a first communication system; assigning an originating agent to establish a first call half connection with the first communication system; processing the call request signal to generate a processed call request signal; determining a route for the call connection as a function of the processed call request signal; assigning a terminating agent as a function of the route, the terminating agent establishing a second call half connection with a destination of the call connection; and connecting the originating agent and the terminating agent to establish the call connection.
 2. The method according to claim 1, wherein the call request signal includes dialed digits of a called party.
 3. The method according to claim 1, wherein the first communication system includes one of a PLMN and a PSTN.
 4. The method according to claim 1, wherein the originating agent and the terminating agent each include a software entity providing a call state machine for a predetermined call type.
 5. The method according to claim 4, wherein the predetermined call type includes one of GSM, ISUP, R2 and TUP.
 6. The method according to claim 1, wherein the steps of processing the call request signal and determining a route are performed via a translator and router function interacting with the originating agent.
 7. The method according to claim 1, wherein the step of connecting the originating agent and the terminating agent further includes connecting the originating agent to the terminating agent via one of a native protocol of the terminating agent and a generic protocol.
 8. A method for establishing a call connection, comprising the steps of: converting, in a first agent of a first communication system, a call setup message from a first agent format to a standard format; transmitting the standard format call setup message to a second agent of the first communication system, the second agent being associated with a destination of the call connection; and converting, in the second agent of the first communication system, the standard format call setup message to a second agent format call setup message.
 9. The method according to claim 8, wherein the first communication system and the destination of the call connection include one of a PLMN, a PSTN and an optical fiber telecommunication system.
 10. The method according to claim 8, wherein the first agent and the second agent include one of a mobile agcnt, an ISUP agent, a R2 agent and a TUP agent.
 11. The method according to claim 8, further comprising the steps of: determining, via the second agent, that the call connection is to be redirected to a second destination; converting the second agent format call setup message to the standard format; transmitting the standard format call setup message to a third agent of the first communication system, the third agent being associated with the second destination of the call connection, and converting, in the third agent of the first communication system, the standard format call setup message to a third agent format call setup message.
 12. A memory for storing data for access by an application program being executed on a computer system, comprising: a standard protocol object stored in the memory, the standard protocol object including a predetermined set of standard messages; at least one unique protocol object stored in the memory, the at least one unique protocol object including a predetermined set of unique messages, each message in the predetermined set of standard messages corresponding to a respective one of the plurality of unique messages to provide a generic protocol to establish a call connection between a first processing agent and a second processing agent; and a translation object stored in the memory to provide an association between the predetermined set of unique messages and the predetermined set of standard messages.
 13. The memory according to claim 12, wherein the at least one unique protocol object includes one of an ISUP protocol object, an R2 protocol object, a GSM protocol object and a TUP protocol object. 